home *** CD-ROM | disk | FTP | other *** search
- Path: fourier.newcastle.edu.au!peter
- From: peter@fourier.newcastle.edu.au (Peter Moylan)
- Newsgroups: comp.lang.modula2
- Subject: Re: Why Modula-2? was Do any employers use Modula-2?
- Date: 4 Feb 1996 23:13:48 GMT
- Organization: The University of Newcastle
- Message-ID: <4f3ejc$g0t@seagoon.newcastle.edu.au>
- References: <4eqo1l$mko@wariat.wariat.org>
- Reply-To: peter@tesla.newcastle.edu.au
- NNTP-Posting-Host: fourier.newcastle.edu.au
- X-Newsreader: TIN [version 1.2 PL2]
-
- Eric W. Nikitin (enikitin@junior.wariat.org) wrote:
- >I hope people don't get defensive about this question... but
- >I seriously would like an answer to this:
-
- >Why should someone learn Modula-2 rather than one of its
- >'sucessors' Oberon(-2) or Modula-3?
-
- This gets down to a matter of personal preference. I can
- give you my reasons, but you'd get a completely different
- answer if you posted to comp.lang.oberon or comp.lang.modula3.
-
- 1. Compiler availability: Modula-2 is available for most
- machines, but Oberon and Modula-3 have much more restricted
- support so far. There's now an ISO standard for Modula-2,
- although admittedly it will be a while before the
- compiler-writers start sticking to the standard. Modula-3
- has some good ideas but because of the way it was developed
- it's almost a proprietary product which might or might not
- be ported to other platforms. I believe that the Oberon
- people are looking at developing a standard, but I also
- believe that it's going to take them a long time.
-
- 2. Garbage collection. This is an issue for me, might not be
- an issue for others. I work in real-time applications where
- it's not all that safe to have garbage collection going on
- behind the scenes. I know there are ways to turn it off,
- but if you do that then you throw away some of the better
- features of Modula-3 and might as well stick to Modula-2.
-
- 3. Oberon was designed in such a way that it's not just a
- language, it's a language plus something like an operating
- system. There are things in the design that make it
- difficult to separate these two things. If you don't like
- the interface, then Oberon is a bit of a pain to use.
- In addition, it means that Oberon is firmly committed to
- "workstation" type applications; it's not clear that it
- would be a viable choice for things like embedded systems.
-
- 4. Finally, I happen to think that in many of its properties
- Oberon is a step backwards rather than an advance. The
- extensible records of Oberon are very nice (much better than
- the usual OO approaches), but there are some features of
- Modula-2 which IMO are worth having and which have been
- deleted from Oberon.
-
- One thing that really bugs me about Oberon is the lack of
- separate definition modules. The Oberon people claim this as
- an advance, but I'm not convinced. If you use the Oberon
- feature of looking at a module interface (it's a bit like
- automatic generation of a definition module) then what you
- get is really cryptic: no comments, unclear workarounds to
- compensate for the missing enumerated types, etc. It feels
- a bit like using the C/grep approach. I accept that there are
- some genuine important advances in Oberon, but it has a long
- way to go before becoming programmer-friendly. At the
- moment it's a bit like the Unix design: nice to use if you
- happen to be a guru who understands all the internals, but
- too obscure for the average programmer.
-
- Modula-3 is something different. I could accept Modula-3 as
- a genuine upgrade of Modula-2, but it's not going to go
- anywhere unless it gets ported to lots of platforms.
-
- --
- Peter Moylan peter@ee.newcastle.edu.au
- ftp://ee.newcastle.edu.au/pub/www/Moylan.html
-